Known Issues and Limitations

This chapter describes the known issues and limitations as well as corresponding solutions that you should consider when building your Azure cloud infrastructure, to which you will deploy CloudBlue Commerce.

Limitation: The Operations Management Node must have direct (proxy-less) access to the Internet for these operations:

Initial deployment using install.py
Deployment of the GDPR application
Deployment of the UI cluster
Adding a brand to UI cluster

Solution: Ensure direct access to the Internet from your Operations Management Node.

Limitation: The proxy on the Operations Management Node must be disabled to be able to deploy the Billing Application Node.

Solution:

To ensure the correct deployment of the Billing Application Node:

Before deploying your Billing Application Node, disable the proxy in your Operations Management Node database. To do so, execute the following query in the Operations Management Node database:

Note: The query will rename the installed package ‘PrivacyProxy’ to 'DisabledPrivacyProxy'.
```
UPDATE packages SET name = 'DisabledPrivacyProxy'
WHERE pkg_id =
     (SELECT pkg_id
      FROM packages
      JOIN components
      USING (pkg_id)
      WHERE name = 'PrivacyProxy' );
```
Deploy your Billing Application Node as described in the Linux Platform Deployment Guide.

Re-enable the proxy. To do so, revert the name of the package 'PrivacyProxy' by executing the following query:

UPDATE packages SET name='PrivacyProxy'
WHERE pkg_id =
     (SELECT pkg_id
      FROM packages
      JOIN components
      USING (pkg_id)
      WHERE name = 'DisabledPrivacyProxy');

Limitation: Odin Automation may fail to register a Windows virtual machine that you deployed to your Azure cloud infrastructure to use it, for example, as a service node for a module that runs on Windows. Additional manual configuration may be necessary.

Root cause: The problem may occur because Azure does not automatically complete the 'Primary Dns Suffix' configuration parameter for virtual machines by using the value of the 'DNS Suffix Search List' field. As a result, for a Windows virtual machine in Azure, PAAgent does not receive a Fully Qualified Domain Name (FQDN) and uses the Host Name value instead in the virtual machine token validation process, which fails.

Solution:

Perform this manual configuration:

To ensure that PAAgent receives an FQDN, obtain the value of the DNS Suffix Search List field to complete the Primary Dns Suffix field:
1. In the command line, view the IP configuration of the virtual machine that failed to register by using the command ipconfig /all.
  For example:
```
> ipconfig /all
Windows IP Configuration
Host Name . . . . . . . . . . . . : winvm
Primary Dns Suffix . . . . . . .  :
Node Type . . . . . . . . . . . . : Hybrid
IP Routing Enabled. . . . . . . . : No
WINS Proxy Enabled. . . . . . . . : No
DNS Suffix Search List. . . . . . : ohn2vuaburpethhtzyntykrblb.ax.internal.cloudapp.net
```
2. The 'Primary Dns Suffix' parameter is empty. Copy the first record in the 'DNS Suffix Search List' field to complete the Primary DNS Suffix field as described below.
Assign the value of the first record in the 'DNS Suffix Search List' field to the 'Primary DNS Suffix' field for the virtual machine. For example:
1. In the Windows GUI, go to Control Panel > System and Security > System.
2. In the Computer name, domain, and workgroup settings, click Change settings.
3. To rename the node, click Change. Click More. Complete the Primary DNS suffix of this computer field with the value from the 'DNS Suffix Search List' field above. Save the changes.
To apply the changes, restart the virtual machine.

Limitation: Additional manual steps are necessary to add a Windows node to Odin Automation deployed to Azure cloud, and configure firewall for the node.

Root cause: When you add a Windows node to Odin Automation deployed to Azure cloud while WinRM (Windows Remote Management) is enabled, it is impossible to configure firewall for the node. By contrast, when you try to add a Windows node while WinRM is disabled, SharedNodeRegistrator tries to enable WinRM by using the script remote_conf_winrm.sh. Among various things, the script adds some firewall rules for communication between the node and the PAAgent.

Solution:

Perform these Windows Server 2012 R2 firewall configuration steps in command line:

Open PAAgent port 8352 for incoming TCP connections:
netsh advfirewall firewall add rule name="POA in" protocol=TCP dir=in profile=any localport=8352 remoteip=any localip=any action=allow
Open PAAgent second port 8354 for incoming TCP connections:
netsh advfirewall firewall add rule name="POA in 2" protocol=TCP dir=in profile=any localport=8354 remoteip=any localip=any action=allow
Open WinRM default 5985 port for incoming HTTP connections:
netsh advfirewall firewall add rule name="WinRM in" protocol=TCP dir=in profile=any localport=5985 remoteip=any localip=any action=allow

Limitation: If you use the default DHCP configuration, service nodes will be assigned different IP addresses after each restart. This will make the nodes inaccessible.

Solution: Assign static private IP addresses to service nodes.

Limitation (only for Windows-based service nodes): Virtual machines cannot be attached if passwords contain the "^" and "&" characters.

Solution: Do not use the "^" and "&" characters in passwords.

Limitations related to WebHosting Plesk

Limitation: You cannot use dedicated IP addresses for websites. IP pools are not supported.

Solution: Use only shared IP addresses for website hosting.

Limitation: If you set up NAT rules after adding a service node, you need to update the settings of the service node in Operations.

Solution: Update the settings of service nodes in Services > WebHosting Plesk > Service Nodes > Refresh.

Limitation: Private (internal) IP addresses are shown on Plesk screens.

Solution: If you want Plesk screens to show public IP addresses instead of private ones, you need to manually configure NAT rules at each Plesk-based service node. You need to do this on clean nodes that do not host any websites, right after connecting the nodes and before you start using them. You can configure the NAT rules in any of the following ways:

Using the console: # plesk bin ipmanage -u <privateIp> -public_ip <publicIp>
Using the Plesk panel: Log in as admin, go to Server Management > Tools & Settings > IP addresses, select the address (primary IP configuration, there must be only one such address), click Public IP addresses, specify the public IP address, and click OK.

Limitation: Azure blocks outbound connections on TCP port 25.

Solution: You can enable connections on this port by filing a request to the Microsoft technical support. For details, see https://docs.plesk.com/en-US/onyx/deployment-guide/plesk-installation-and-upgrade-on-public-cloud-services/installing-plesk-on-microsoft-azure.77481/.

Limitation: You might experience issues with FTP connections in the active mode.

Solution: Configure the passive FTP mode using the instructions at https://docs.plesk.com/en-US/onyx/deployment-guide/plesk-installation-and-upgrade-on-public-cloud-services/installing-plesk-on-microsoft-azure/configuring-the-passive-ftp-mode-on-a-microsoft-azure-instance.79079/.